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1. Introduction 


The purpose of this document is to describe coexistence 
between version 2 of the Internet-standard Network Management 
Framework, termed the SNMP version 2 framework (SNMPv2) [1], 
and the original Internet-standard Network Management 
Framework (SNMPv1), which consists of these three documents: 


RFC 1155 [2] which defines the Structure of Management 
Information (SMI), the mechanisms used for describing and 
naming objects for the purpose of management. 


RFC 1212 [3] which defines a more concise description 
mechanism, which is wholly consistent with the SMI. 


RFC 1157 [4] which defines the Simple Network Management 


Protocol (SNMP), the protocol used for network access to 
managed objects. 
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2. Management Information 


The SNMPv2 approach towards describing collections of managed 
objects is nearly a proper superset of the approach defined in 
the Internet-standard Network Management Framework. For 
example, both approaches use ASN.1 [5] as the basis fora 
formal descriptive notation. Indeed, one might note that the 
SNMPv2 approach largely codifies the existing practice for 
defining MIB modules, based on extensive experience with the 
current framework. 


The SNMPv2 documents which deal with information modules are: 


Structure of Management Information for SNMPv2 [6], which 
defines concise notations for describing information 
modules, managed objects and notifications; 


Textual Conventions for SNMPv2 [7], which defines a 
concise notation for describing textual conventions, and 
also defines some initial conventions; and, 


Conformance Statements for SNMPv2 [8], which defines 
concise notation for describing compliance and 
capabilities statements. 


The following sections consider the three areas: MIB modules, 
compliance statements, and capabilities statements. 


MIB modules defined using the current framework may continue 
to be used with the SNMPv2 protocol. However, for the MIB 
modules to conform to the SNMPv2 framework, the following 
changes are required: 


2.1. Object Definitions 


In general, conversion of a MIB module does not require the 
deprecation of the objects contained therein. Only if the 
semantics of an object truly changes should deprecation be 
performed. 


(1) The IMPORTS statement must reference SNMPv2-SMI, instead 
of RFC1155-SMI and RFC-1212. 
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Case, 


The MODULE-IDENTITY macro must be invoked immediately 
after any IMPORTs or EXPORTs statement. 


For any descriptor which contains the hyphen character, 
the hyphen character is removed. 


For any object with an integer-valued SYNTAX clause, in 
which the corresponding INTEGER does not have a range 
restriction (i.e., the INTEGER has neither a defined set 
of named-number enumerations nor an assignment of lower- 
and upper-bounds on its value), the object must have the 
value of its SYNTAX clause changed to Integer32. 


For any object with a SYNTAX clause value of an 
enumerated INTEGER, the hyphen character is removed from 
any named-number labels which contain the hyphen 
character. 


For any object with a SYNTAX clause value of Counter, the 
object must have the value of its SYNTAX clause changed 
to Counter32. 


For any object with a SYNTAX clause value of Gauge, the 
object must have the value of its SYNTAX clause changed 
to Gauge32. 


For all objects, the ACCESS clause must be replaced by a 
MAX-ACCESS clause. The value of the MAX-ACCESS clause is 
the same as that of the ACCESS clause unless some other 
value makes "protocol sense" as the maximal level of 
access for the object. In particular, object types for 
which instances can be explicitly created by a protocol 
set operation, will have a MAX-ACCESS clause of "read- 
create". If the value of the ACCESS clause is "write- 
only", then the value of the MAX-ACCESS clause is "read- 
write", and the DESCRIPTION clause notes that reading 
this object will result implementation-specific results. 


For any columnar object which is used solely for instance 
identification in a conceptual row, the object must have 
the value of its MAX-ACCESS clause set to "not- 
accessible", unless all columnar objects of the 
conceptual row are used for instance identification, in 
which case, the MAX-ACCESS clause for one of them must be 
something other than "not-accessible". 
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(10) 


(15) 


For all objects, if the value of the STATUS clause is 
"mandatory", the value must be replaced with "current". 


For all objects, if the value of the STATUS clause is 
"optional", the value must be replaced with "obsolete". 


For any object not containing a DESCRIPTION clause, the 
object must have a DESCRIPTION clause defined. 


For any object corresponding to a conceptual row which 
does not have an INDEX clause, the object must have 
either an INDEX clause or an AUGMENTS clause defined. 


For any object with an INDEX clause that references an 
object with a syntax of NetworkAddress, the value of the 
STATUS clause of the both objects is changed to 
"obsolete". 


For any object containing a DEFVAL clause with an OBJECT 
IDENTIFIER value which is expressed as a collection of 
sub-identifiers, change the value to reference a single 
ASN.1 identifier. 


Other changes are desirable, but not necessary: 


(1) 


Case, 


Creation and deletion of conceptual rows is inconsistent 
using the current framework. The SNMPv2 framework 
corrects this. As such, if the MIB module undergoes 
review early in its lifetime, and it contains conceptual 
tables which allow creation and deletion of conceptual 
rows, then it may be worthwhile to deprecate the objects 
relating to those tables and replacing them with objects 
defined using the new approach. 


For any object with a string-valued SYNTAX clause, in 
which the corresponding OCTET STRING does not have a size 
restriction (i.e., the OCTET STRING has no assignment of 
lower- and upper-bounds on its length), one might 
consider defining the bounds for the size of the object. 


For all textual conventions informally defined in the MIB 
module, one might consider redefining those conventions 
using the TEXTUAL-CONVENTION macro. Such a change would 
not necessitate deprecating objects previously defined 
using an informal textual convention. 
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(4) For any object which represents a measurement in some 
kind of units, one might consider adding a UNITS clause 
to the definition of that object. 


(5) For any conceptual row which is an extension of another 
conceptual row, i.e., for which subordinate columnar 
objects both exist and are identified via the same 
semantics as the other conceptual row, one might consider 
using an AUGMENTS clause in place of the INDEX clause for 
the object corresponding to the conceptual row which is 
an extension. 


Finally, when encountering common errors in SNMPvl MIB 
modules: 


(1) For any object with a SYNTAX clause value of an 
enumerated INTEGER, if a named-number enumeration is 
present with a value of zero, the value of the STATUS 
clause of that object is changed to "obsolete". 


(2) For any non-columnar object that is instanced as if it 
were immediately subordinate to a conceptual row, the 
value of the STATUS clause of that object is changed to 
"obsolete". 


(3) For any conceptual row object that is not contained 
immediately subordinate to a conceptual table, the value 
of the STATUS clause of that object (and all subordinate 
objects) is changed to "obsolete". 

2.2. Trap Definitions 

If a MIB module is changed to conform to the SNMPv2 framework, 

then each occurrence of the TRAP-TYPE macro must be changed to 

a corresponding invocation of the NOTIFICATION-TYPE macro: 

(1) The IMPORTS statement must not reference RFC-1215. 


(2) The ENTERPRISES clause must be removed. 


(3) The VARIABLES clause must be renamed to the OBJECTS 
clause. 
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(4) The STATUS clause must be added. 


(5) The value of an invocation of the NOTIFICATION-TYPE macro 
is an OBJECT IDENTIFIER, not an INTEGER, and must be 
changed accordingly. 


2.3. Compliance Statements 


For those information modules which are "standard", a 
corresponding invocation of the MODULE-COMPLIANCE macro must 
be included within the information module (or in a companion 
information module), and any commentary text in the 
information module which relates to compliance must be 
removed. Typically this editing can occur when the 
information module undergoes review. 


2.4. Capabilities Statements 


In the current framework, the informational document [9] uses 
the MODULE-CONFORMANCE macro to describe an agent’s 
capabilities with respect to one or more MIB modules. 
Converting such a description for use with the SNMPv2 
framework requires these changes: 


(1) Use the macro name AGENT-CAPABILITIES instead of MODULE- 
CONFORMANCE. 


(2) The STATUS clause must be added. 
(3) For all occurrences of the CREATION-REQUIRES clause, note 


the slight change in semantics, and omit this clause if 
appropriate. 
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3. Protocol Operations 
The SNMPv2 documents which deal with protocol operations are: 


Protocol Operations for SNMPv2 [10], which defines the 
syntax and semantics of the operations conveyed by the 
protocol; and, 


Transport Mappings for SNMPv2 [11], which defines how the 
protocol operations are carried over different transport 
services. 


The following section considers two areas: the proxy behavior 
between a SNMPv2 entity and a SNMPvl agent; and, the behavior 
of "bi-lingual" protocol entities acting in a manager role. 


3.1. Proxy Agent Behavior 


To achieve coexistence at the protocol-level, a proxy 
mechanism may be used. A SNMPv2 entity acting in an agent 
role may be implemented and configured to act in the role of a 
proxy agent. 


3.1.1. SNMPv2 -> SNMPv1 


When converting requests from a SNMPv2 entity acting ina 
manager role into requests sent to a SNMPvl entity acting in 
an agent role: 


(1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-— 
PDU is received, then it is passed unaltered by the proxy 
agent. 


(2) If a GetBulkRequest-PDU is received, the proxy agent sets 
the non-repeaters and max-repetitions fields to zero, and 
sets the tag of the PDU to GetNextRequest-—PDU. 


3.1.2. SNMPvl -> SNMPv2 
When converting responses received from a SNMPvl entity acting 


in an agent role into responses sent to a SNMPv2 entity acting 
in a manager role: 
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(1) 


Case, 


If a GetResponse-PDU is received, then it is passed 
unaltered by the proxy agent. Note that even though a 
SNMPv2 entity will never generate a Response-PDU with a 
error-status field having a value of ‘noSuchName’, 
‘badValue’, or ‘readOnly’, the proxy agent must not 
change this field. This allows the SNMPv2 entity acting 
in a manager role to interpret the response correctly. 


If a GetResponse-PDU is received with an error-status 
field having a value of ‘tooBig’, the proxy agent will 
remove the contents of the variable-bindings field before 
propagating the response. Note that even though a SNMPv2 
entity will never generate a ‘tooBig’ in response to a 
GetBulkRequestPDU, the proxy agent must propagate such a 
response. 


If a Trap-PDU is received, then it is mapped into a 
SNMPv2-Trap-PDU. This is done by prepending onto the 
variable-bindings field two new bindings: sysUpTime.0 
[12], which takes its value from the timestamp field of 
the Trap-PDU; and, snmpTrapOID.0 [13], which is 
calculated thusly: if the value of generic-trap field is 
‘enterpriseSpecific’, then the value used is the 
concatenation of the enterprise field from the Trap-PDU 
with two additional sub-identifiers, ‘0’, and the value 
of the specific-trap field; otherwise, the value of the 
corresponding trap defined in [13] is used. (For 
example, if the value of the generic-trap field is 
‘coldStart’, then the coldStart trap [13] is used.) Then, 
one new binding is appended onto the variable-bindings 
field: snmpTrapEnterpriseOID.0 [13], which takes its 
value from the enterprise field of the Trap-PDU. To 
determine the destinations for the SNMPv2-Trap-PDU, the 
proxy agent applies the procedures defined in Section 
4.2.6 of [10], with the exception that no check is made 
to see if the instances associated with this trap are 
present in the proxy agent’s view. 
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3.2. Bi-lingual Manager Behavior 


To achieve coexistence at the protocol-level, a protocol 
entity acting in a manager role might support both SNMPv1 and 
SNMPv2. When a management application needs to contact a 
protocol entity acting in an agent role, the entity acting in 
a manager role consults a local database to select the correct 
management protocol to use. 


In order to provide transparency to management applications, 


the entity acting in a manager role must map operations as if 
it were acting as a proxy agent. 
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6. Security Considerations 


Security issues are not discussed in this memo. 
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